As is known, a multi-application IC card is an IC card storing a plurality of applications that provides different purpose services, for example a loyalty application, an identification application, a credit card application, and similar applications. The multi-application IC card is used as a substitute for multiple IC cards, each storing a single application, since it is more comfortably held in a wallet, and at the same time requiring lower costs of updating applications after issuance, as well as decreasing their development and deployment costs.
Moreover, the multi-application IC card allows commercial synergies between partners since each partner provides its own application so that different applications may communicate or share information inside the multi-application IC card, leading to new business opportunities. For example, a multi-application IC card may comprise an electronic purse application, managing an available credit, and a frequent flyer application, representing the fidelity of a client. When the IC card electronic purse application is used to pay for an airline flight, the frequent flyer application may be updated, for example tracking that a new flight has been booked with a specific company. In other words, in a multi-application IC card, sharing of information or interaction between more than one application may occur.
More particularly, an operating system for the multi-application IC card, for example, Java Card, Multos, or Smart Card for Windows, is responsible for managing such interaction between applications, for example, allowing or locking the information sharing.
The operating system comprises a security policy that is a set of rules and practices regulating, protecting, and distributing sensitive information, as well as regulating the interaction between applications. A security violation occurs when a user, or an application, circumvents or defeats the controls of the operating system, in order to obtain unauthorized access to information, regardless of the security policy.
The security policy in a multi-application IC card is more than a simple concatenation of rules related to the correspondent single applications. In fact, the operating system not only manages the IC card applications and their access to resources, like I/O, memory, random number generator, crypto engine, and so on, but also the interactions between applications and their sharing, that depends on the state or the security policy of a single application.
Moreover, the security policy, especially in a multi-application IC card, may be static or dynamic, meaning that the rules defining the security policy may be changed during the lifetime of the IC card. For example, during a first part of the multi-application IC card lifecycle, an application A may provide services to an application B and deny the same services to an application C. In this case the security policy relating to application A specifies that application B may be served, and application C may not be served.
When a new application D needing the services provided by the application A is stored on the multi-application IC card, for example by an issuer, the security policy of the application A should be changed so to enable the application D to use the services provided by A. Moreover, the security policy is defined not only in the operating system, for example, cabled inside its code, but also inside each single application, for example, defining inside the code of an application A, that another application B may be served, while a third application C may not.
A dynamic change of a security policy, for example, due to the introduction of a new application inside the multi-application IC card, involves not only a modification of the operative system but also a modification of the application code of each application included in the multi-application IC card because the security policy is, in part, controlled by the fixed rules of the operating system, and in other parts controlled directly by the applications.
In other words, by an enforcement or modification of application security policies is based on a proprietary approach, depending on application developers, and not on common functions, usable by all the applications stored in the multi-application IC card.
For this reason, dynamic management of the multi-application IC card security policy is very limited as is the reaction to its violation. Also, such a reaction is generally fixed inside the code of each application or inside the operating system and difficult to modify dynamically. Moreover, according to the multi-application IC card currently known, violation reactions may be checked only when the application is in execution, since it depends on a plurality of controls spread into the operating system and into each single application.
It is also worth noting that a multi-application IC card generally involves many participants, for example an issuer, an end user, an application provider, and a card operator, each participant potentially requiring the storing of a specific application. In this way, the security policy often requires modification or updating, in order to build a cooperative optimization usage of the memory, and to correctly regulate data and service sharing between applications.
With reference to FIG. 1, a multi-application IC card is schematically shown, according to a Java Card Security Model based on the Sandbox security model. Applications #3, #4, and #5 cannot interact with each other directly, but only through the Java Card Runtime Environment (JCRE) #1 which can enforce the Java Card Security Policy according to a Java Card Specification.
Object sharing is performed through the JCRE #1 that is a trusted entity providing a mediation function between applications, for example, requesting services and server applications owning server objects. More particularly, the process could be considered in this way: an application, for example, application #3 requests from JCRE #1 the reference to a shared object. JCRE #1 forwards the request together with an identification (ID) of the requesting application to a server application owning the shareable object.
The server application returns to the JCRE the reference to the shareable object only if application #1 has the permission to exploit the requested services. The permission check is implemented at the application level. Once the reference to a shareable interface object is provided to application #1, the owner of the object cannot revoke or modify the access right to the corresponding service. Accordingly, the policy and the reaction to its violation is static, defined by the specification, and cannot be managed at the application level.